JavaScript Module Federation-இல் தேர்ச்சி பெறுதல்: பகிரப்பட்ட Scope மற்றும் சார்புநிலை பகிர்வின் சக்தி

விரைவாக வளர்ந்து வரும் வலை மேம்பாட்டுத் துறையில், அளவிடக்கூடிய மற்றும் பராமரிக்கக்கூடிய செயலிகளை உருவாக்குவது என்பது பெரும்பாலும் மேம்பட்ட கட்டமைப்பு முறைகளைப் பின்பற்றுவதை உள்ளடக்கியுள்ளது. இவற்றில், மைக்ரோஃபிரண்ட்எண்டுகள் என்ற கருத்து குறிப்பிடத்தக்க கவனத்தைப் பெற்றுள்ளது, இது குழுக்கள் ஒரு செயலியின் பகுதிகளை சுயாதீனமாக உருவாக்கி வரிசைப்படுத்த அனுமதிக்கிறது. இந்த சுயாதீன அலகுகளுக்கு இடையே தடையற்ற ஒருங்கிணைப்பு மற்றும் திறமையான குறியீடு பகிர்வை செயல்படுத்துவதில் முக்கியப் பங்கு வகிப்பது Webpack-இன் Module Federation செருகுநிரல் ஆகும், மேலும் அதன் சக்தியின் ஒரு முக்கிய அம்சம் பகிரப்பட்ட ஸ்கோப் (shared scope) ஆகும்.

இந்த விரிவான வழிகாட்டி JavaScript Module Federation-க்குள் உள்ள பகிரப்பட்ட ஸ்கோப் பொறிமுறையை ஆழமாக ஆராய்கிறது. அது என்ன, சார்புநிலை பகிர்வுக்கு அது ஏன் அவசியம், அது எப்படி செயல்படுகிறது, மற்றும் அதை திறம்பட செயல்படுத்துவதற்கான நடைமுறை உத்திகளை நாம் ஆராய்வோம். எங்கள் நோக்கம், பல்வேறு உலகளாவிய மேம்பாட்டுக் குழுக்களில் மேம்பட்ட செயல்திறன், குறைக்கப்பட்ட பண்டில் அளவுகள் மற்றும் மேம்பட்ட டெவலப்பர் அனுபவத்திற்காக இந்த சக்திவாய்ந்த அம்சத்தைப் பயன்படுத்த டெவலப்பர்களுக்கு அறிவை வழங்குவதாகும்.

JavaScript Module Federation என்றால் என்ன?

பகிரப்பட்ட ஸ்கோப்பிற்குள் முழுமையாகச் செல்வதற்கு முன், Module Federation-இன் அடிப்படைக் கருத்தைப் புரிந்துகொள்வது முக்கியம். Webpack 5 உடன் அறிமுகப்படுத்தப்பட்ட, Module Federation என்பது ஒரு பில்ட்-டைம் மற்றும் ரன்-டைம் தீர்வாகும், இது ஜாவாஸ்கிரிப்ட் செயலிகள் தனித்தனியாக தொகுக்கப்பட்ட செயலிகளுக்கு இடையே குறியீட்டை (நூலகங்கள், கட்டமைப்புகள் அல்லது முழுமையான கூறுகள் போன்றவை) டைனமிக்காகப் பகிர அனுமதிக்கிறது. இதன் பொருள் என்னவென்றால், நீங்கள் பல தனித்துவமான செயலிகளைக் கொண்டிருக்கலாம் (பெரும்பாலும் 'ரிமோட்கள்' அல்லது 'நுகர்வோர்' என்று குறிப்பிடப்படுகிறது), அவை ஒரு 'கண்டெய்னர்' அல்லது 'ஹோஸ்ட்' செயலியிலிருந்து குறியீட்டை ஏற்ற முடியும், மற்றும் நேர்மாறாகவும்.

Module Federation-இன் முதன்மை நன்மைகள் பின்வருமாறு:

• குறியீடு பகிர்வு: பல செயலிகளில் தேவையற்ற குறியீட்டை நீக்குதல், ஒட்டுமொத்த பண்டில் அளவுகளைக் குறைத்தல் மற்றும் ஏற்றுதல் நேரங்களை மேம்படுத்துதல்.
• சுயாதீனமான வரிசைப்படுத்தல்: குழுக்கள் ஒரு பெரிய செயலியின் வெவ்வேறு பகுதிகளை சுயாதீனமாக உருவாக்கி வரிசைப்படுத்தலாம், இது சுறுசுறுப்பு மற்றும் விரைவான வெளியீட்டு சுழற்சிகளை வளர்க்கிறது.
• தொழில்நுட்ப சார்பற்ற தன்மை: முதன்மையாக Webpack உடன் பயன்படுத்தப்பட்டாலும், இது வெவ்வேறு பில்ட் கருவிகள் அல்லது கட்டமைப்புகளுக்கு இடையில் பகிர்வை ஒரு அளவிற்கு எளிதாக்குகிறது, இது நெகிழ்வுத்தன்மையை ஊக்குவிக்கிறது.
• ரன்டைம் ஒருங்கிணைப்பு: செயலிகள் ரன்டைமில் உருவாக்கப்படலாம், இது டைனமிக் புதுப்பிப்புகள் மற்றும் நெகிழ்வான செயலி கட்டமைப்புகளை அனுமதிக்கிறது.

சிக்கல்: மைக்ரோஃபிரண்ட்எண்டுகளில் தேவையற்ற சார்புநிலைகள்

நீங்கள் பல மைக்ரோஃபிரண்ட்எண்டுகளைக் கொண்ட ஒரு சூழ்நிலையைக் கவனியுங்கள், அவை அனைத்தும் React போன்ற ஒரு பிரபலமான UI நூலகத்தின் அதே பதிப்பையோ அல்லது Redux போன்ற ஒரு நிலை மேலாண்மை நூலகத்தையோ சார்ந்துள்ளன. பகிர்வதற்கான ஒரு பொறிமுறை இல்லாமல், ஒவ்வொரு மைக்ரோஃபிரண்ட்எண்டும் இந்த சார்புநிலைகளின் சொந்த நகலை பண்டில் செய்யும். இது பின்வருவனவற்றிற்கு வழிவகுக்கிறது:

• பெரிய பண்டில் அளவுகள்: ஒவ்வொரு செயலியும் பொதுவான நூலகங்களை தேவையற்ற முறையில் நகலெடுக்கிறது, இது பயனர்களுக்கு பெரிய பதிவிறக்க அளவுகளுக்கு வழிவகுக்கிறது.
• அதிகரித்த நினைவக நுகர்வு: உலாவியில் ஏற்றப்பட்ட ஒரே நூலகத்தின் பல நிகழ்வுகள் அதிக நினைவகத்தைப் பயன்படுத்தக்கூடும்.
• சீரற்ற நடத்தை: செயலிகள் முழுவதும் பகிரப்பட்ட நூலகங்களின் வெவ்வேறு பதிப்புகள் நுட்பமான பிழைகள் மற்றும் பொருந்தக்கூடிய சிக்கல்களுக்கு வழிவகுக்கும்.
• வீணான நெட்வொர்க் வளங்கள்: பயனர்கள் வெவ்வேறு மைக்ரோஃபிரண்ட்எண்டுகளுக்கு இடையில் செல்லும்போது ஒரே நூலகத்தை பலமுறை பதிவிறக்கம் செய்யலாம்.

இந்த சவால்களுக்கு ஒரு நேர்த்தியான தீர்வை வழங்கும் Module Federation-இன் பகிரப்பட்ட ஸ்கோப் இங்குதான் devreக்கு வருகிறது.

Module Federation-இன் பகிரப்பட்ட Scope-ஐப் புரிந்துகொள்ளுதல்

பகிரப்பட்ட ஸ்கோப், பெரும்பாலும் Module Federation செருகுநிரலில் உள்ள shared விருப்பம் வழியாக உள்ளமைக்கப்படுகிறது, இது பல சுயாதீனமாக வரிசைப்படுத்தப்பட்ட செயலிகள் சார்புநிலைகளைப் பகிர உதவும் பொறிமுறையாகும். உள்ளமைக்கப்படும்போது, Module Federation ஒரு குறிப்பிட்ட சார்புநிலையின் ஒரே ஒரு நிகழ்வு ஏற்றப்பட்டு, அது தேவைப்படும் அனைத்து செயலிகளுக்கும் கிடைக்கச் செய்வதை உறுதி செய்கிறது.

அதன் மையத்தில், பகிரப்பட்ட ஸ்கோப் பகிரப்பட்ட மாட்யூல்களுக்கு ஒரு உலகளாவிய பதிவேடு அல்லது கண்டெய்னரை உருவாக்குவதன் மூலம் செயல்படுகிறது. ஒரு செயலி பகிரப்பட்ட சார்புநிலையைக் கோரும்போது, Module Federation இந்த பதிவேட்டைச் சரிபார்க்கிறது. சார்புநிலை ஏற்கனவே இருந்தால் (அதாவது, மற்றொரு செயலி அல்லது ஹோஸ்டால் ஏற்றப்பட்டிருந்தால்), அது இருக்கும் நிகழ்வைப் பயன்படுத்துகிறது. இல்லையெனில், அது சார்புநிலையை ஏற்றி எதிர்கால பயன்பாட்டிற்காக பகிரப்பட்ட ஸ்கோப்பில் பதிவு செய்கிறது.

உள்ளமைவு பொதுவாக இப்படி இருக்கும்:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... other webpack configurations
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

பகிரப்பட்ட சார்புநிலைகளுக்கான முக்கிய உள்ளமைவு விருப்பங்கள்:

• singleton: true: இது ஒருவேளை மிக முக்கியமான விருப்பமாக இருக்கலாம். true என அமைக்கப்படும்போது, இது அனைத்து நுகர்வோர் செயலிகளிலும் பகிரப்பட்ட சார்புநிலையின் ஒரே ஒரு நிகழ்வு மட்டுமே ஏற்றப்படுவதை உறுதி செய்கிறது. பல செயலிகள் ஒரே சிங்கிள்டன் சார்புநிலையை ஏற்ற முயற்சித்தால், Module Federation அவற்றுக்கு ஒரே நிகழ்வை வழங்கும்.
• eager: true: இயல்பாக, பகிரப்பட்ட சார்புநிலைகள் சோம்பேறித்தனமாக ஏற்றப்படுகின்றன, அதாவது அவை வெளிப்படையாக இறக்குமதி செய்யப்படும்போது அல்லது பயன்படுத்தப்படும்போது மட்டுமே பெறப்படுகின்றன. eager: true என அமைப்பது, செயலி தொடங்கும்போதே சார்புநிலையை ஏற்றும்படி கட்டாயப்படுத்துகிறது, அது உடனடியாகப் பயன்படுத்தப்படாவிட்டாலும் கூட. இது கட்டமைப்புகள் போன்ற முக்கியமான நூலகங்களுக்கு ஆரம்பத்திலிருந்தே கிடைப்பதை உறுதிசெய்ய பயனுள்ளதாக இருக்கும்.
• requiredVersion: '...': இந்த விருப்பம் பகிரப்பட்ட சார்புநிலையின் தேவையான பதிப்பைக் குறிப்பிடுகிறது. Module Federation கோரப்பட்ட பதிப்பைப் பொருத்த முயற்சிக்கும். பல செயலிகளுக்கு வெவ்வேறு பதிப்புகள் தேவைப்பட்டால், Module Federation இதைக் கையாளும் வழிமுறைகளைக் கொண்டுள்ளது (பின்னர் விவாதிக்கப்படும்).
• version: '...': பகிரப்பட்ட ஸ்கோப்பில் வெளியிடப்படும் சார்புநிலையின் பதிப்பை நீங்கள் வெளிப்படையாக அமைக்கலாம்.
• import: false: இந்த அமைப்பு Module Federation-ஐ பகிரப்பட்ட சார்புநிலையை தானாக பண்டில் செய்ய வேண்டாம் என்று கூறுகிறது. அதற்கு பதிலாக, அது வெளிப்புறமாக வழங்கப்படும் என்று எதிர்பார்க்கிறது (இது பகிரும்போது இயல்புநிலை நடத்தை).
• packageDir: '...': பகிரப்பட்ட சார்புநிலையைத் தீர்க்க வேண்டிய பேக்கேஜ் கோப்பகத்தைக் குறிப்பிடுகிறது, இது மோனோரெபோக்களில் பயனுள்ளதாக இருக்கும்.

பகிரப்பட்ட Scope சார்புநிலை பகிர்வை எவ்வாறு செயல்படுத்துகிறது

ஒரு நடைமுறை உதாரணத்துடன் இந்த செயல்முறையை உடைப்போம். எங்களிடம் ஒரு முக்கிய 'கண்டெய்னர்' செயலி மற்றும் இரண்டு 'ரிமோட்' செயலிகள், `app1` மற்றும் `app2` இருப்பதாக கற்பனை செய்து கொள்வோம். மூன்று செயலிகளும் `react` மற்றும் `react-dom` பதிப்பு 18-ஐ சார்ந்துள்ளன.

காட்சி 1: கண்டெய்னர் செயலி சார்புநிலைகளைப் பகிர்தல்

இந்த பொதுவான அமைப்பில், கண்டெய்னர் செயலி பகிரப்பட்ட சார்புநிலைகளை வரையறுக்கிறது. Module Federation-ஆல் உருவாக்கப்பட்ட `remoteEntry.js` கோப்பு, இந்த பகிரப்பட்ட மாட்யூல்களை வெளிப்படுத்துகிறது.

கண்டெய்னரின் Webpack உள்ளமைவு (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

இப்போது, `app1` மற்றும் `app2` இந்த பகிரப்பட்ட சார்புநிலைகளைப் பயன்படுத்தும்.

`app1`-இன் Webpack உள்ளமைவு (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

`app2`-இன் Webpack உள்ளமைவு (`app2/webpack.config.js`):

`app2`-க்கான உள்ளமைவு `app1`-ஐப் போலவே இருக்கும், அதே பதிப்பு தேவைகளுடன் `react` மற்றும் `react-dom`-ஐ பகிரப்பட்டதாக அறிவிக்கும்.

ரன்டைமில் இது எப்படி வேலை செய்கிறது:

1. கண்டெய்னர் செயலி முதலில் ஏற்றுகிறது, அதன் பகிரப்பட்ட `react` மற்றும் `react-dom` நிகழ்வுகளை அதன் Module Federation ஸ்கோப்பில் கிடைக்கச் செய்கிறது.
2. `app1` ஏற்றப்படும்போது, அது `react` மற்றும் `react-dom`-ஐக் கோருகிறது. `app1`-ல் உள்ள Module Federation இவை பகிரப்பட்டவை மற்றும் `singleton: true` என குறிக்கப்பட்டிருப்பதைக் காண்கிறது. இது உலகளாவிய ஸ்கோப்பில் இருக்கும் நிகழ்வுகளைச் சரிபார்க்கிறது. கண்டெய்னர் ஏற்கனவே அவற்றை ஏற்றியிருந்தால், `app1` அந்த நிகழ்வுகளை மீண்டும் பயன்படுத்துகிறது.
3. அதேபோல், `app2` ஏற்றப்படும்போது, அதுவும் அதே `react` மற்றும் `react-dom` நிகழ்வுகளை மீண்டும் பயன்படுத்துகிறது.

இது உலாவியில் `react` மற்றும் `react-dom`-இன் ஒரே ஒரு நகல் மட்டுமே ஏற்றப்படுவதற்கு வழிவகுக்கிறது, இது மொத்த பதிவிறக்க அளவை கணிசமாகக் குறைக்கிறது.

காட்சி 2: ரிமோட் செயலிகளுக்கு இடையில் சார்புநிலைகளைப் பகிர்தல்

Module Federation ரிமோட் செயலிகள் தங்களுக்குள் சார்புநிலைகளைப் பகிரவும் அனுமதிக்கிறது. `app1` மற்றும் `app2` இரண்டும் கண்டெய்னரால் பகிரப்படாத ஒரு நூலகத்தைப் பயன்படுத்தினால், அவை இரண்டின் உள்ளமைவுகளிலும் அதை பகிரப்பட்டதாக அறிவித்தால், அவை அதை இன்னும் பகிர்ந்து கொள்ளலாம்.

உதாரணம்: `app1` மற்றும் `app2` இரண்டும் `lodash` என்ற ஒரு பயன்பாட்டு நூலகத்தைப் பயன்படுத்துகின்றன என்று வைத்துக்கொள்வோம்.

`app1`-இன் Webpack உள்ளமைவு (lodash-ஐச் சேர்த்தல்):

            
// ... within ModuleFederationPlugin for app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

`app2`-இன் Webpack உள்ளமைவு (lodash-ஐச் சேர்த்தல்):

            
// ... within ModuleFederationPlugin for app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

இந்த வழக்கில், கண்டெய்னர் வெளிப்படையாக `lodash`-ஐப் பகிராவிட்டாலும், `app1` மற்றும் `app2` ஒரே உலாவி சூழலில் ஏற்றப்பட்டால், தங்களுக்குள் `lodash`-இன் ஒரே ஒரு நிகழ்வைப் பகிர்ந்து கொள்ளும்.

பதிப்பு பொருத்தமின்மைகளைக் கையாளுதல்

சார்புநிலை பகிர்வில் மிகவும் பொதுவான சவால்களில் ஒன்று பதிப்பு பொருந்தக்கூடிய தன்மை. `app1`-க்கு `react` v18.1.0 மற்றும் `app2`-க்கு `react` v18.2.0 தேவைப்பட்டால் என்ன நடக்கும்? Module Federation இந்த சூழ்நிலைகளைக் கையாளுவதற்கான வலுவான உத்திகளை வழங்குகிறது.

1. கடுமையான பதிப்பு பொருத்தம் (requiredVersion-க்கான இயல்புநிலை நடத்தை)

நீங்கள் ஒரு துல்லியமான பதிப்பை (எ.கா., '18.1.0') அல்லது ஒரு கடுமையான வரம்பை (எ.கா., '^18.1.0') குறிப்பிடும்போது, Module Federation இதைச் செயல்படுத்தும். ஒரு செயலி ஏற்கனவே அதைப் பயன்படுத்தும் மற்றொரு செயலியின் தேவையைப் பூர்த்தி செய்யாத ஒரு பதிப்புடன் பகிரப்பட்ட சார்புநிலையை ஏற்ற முயற்சித்தால், அது பிழைகளுக்கு வழிவகுக்கும்.

2. பதிப்பு வரம்புகள் மற்றும் பின்னடைவுகள்

requiredVersion விருப்பம் செமாண்டிக் பதிப்பக (SemVer) வரம்புகளை ஆதரிக்கிறது. உதாரணமாக, '^18.0.0' என்பது 18.0.0 முதல் 19.0.0 வரை (ஆனால் 19.0.0 சேர்க்கப்படவில்லை) உள்ள எந்தப் பதிப்பையும் குறிக்கிறது. பல செயலிகளுக்கு இந்த வரம்பிற்குள் பதிப்புகள் தேவைப்பட்டால், Module Federation பொதுவாக அனைத்து தேவைகளையும் பூர்த்தி செய்யும் மிக உயர்ந்த இணக்கமான பதிப்பை பயன்படுத்தும்.

இதைக் கவனியுங்கள்:

• கண்டெய்னர்: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

கண்டெய்னர் முதலில் ஏற்றப்பட்டால், அது `react` v18.0.0-ஐ (அல்லது அது உண்மையில் பண்டில் செய்யும் எந்தப் பதிப்பையும்) நிறுவுகிறது. `app1` `^18.1.0` உடன் `react`-ஐக் கோரும்போது, கண்டெய்னரின் பதிப்பு 18.1.0-க்கும் குறைவாக இருந்தால் அது தோல்வியடையக்கூடும். இருப்பினும், `app1` முதலில் ஏற்றி `react` v18.1.0-ஐ வழங்கினால், பின்னர் `app2` `^18.2.0` உடன் `react`-ஐக் கோரினால், Module Federation `app2`-இன் தேவைய பூர்த்தி செய்ய முயற்சிக்கும். `react` v18.1.0 நிகழ்வு ஏற்கனவே ஏற்றப்பட்டிருந்தால், v18.1.0 ஆனது `^18.2.0`-ஐ பூர்த்தி செய்யாததால் அது ஒரு பிழையை வீசக்கூடும்.

இதை தணிக்க, பகிரப்பட்ட சார்புநிலைகளை மிகவும் பரந்த ஏற்றுக்கொள்ளக்கூடிய பதிப்பு வரம்புடன் வரையறுப்பது சிறந்த நடைமுறையாகும், பொதுவாக கண்டெய்னர் செயலியில். உதாரணமாக, '^18.0.0'-ஐப் பயன்படுத்துவது நெகிழ்வுத்தன்மையை அனுமதிக்கிறது. ஒரு குறிப்பிட்ட ரிமோட் செயலிக்கு ஒரு புதிய பேட்ச் பதிப்பில் கடுமையான சார்புநிலை இருந்தால், அது அந்த பதிப்பை வெளிப்படையாக வழங்குமாறு உள்ளமைக்கப்பட வேண்டும்.

3. `shareKey` மற்றும் `shareScope` பயன்படுத்துதல்

Module Federation ஒரு மாட்யூல் எந்த விசைக்குக் கீழ் பகிரப்படுகிறது மற்றும் அது எந்த ஸ்கோப்பில் உள்ளது என்பதையும் கட்டுப்படுத்த உங்களை அனுமதிக்கிறது. ஒரே நூலகத்தின் வெவ்வேறு பதிப்புகளை வெவ்வேறு விசைகளின் கீழ் பகிர்வது போன்ற மேம்பட்ட சூழ்நிலைகளுக்கு இது பயனுள்ளதாக இருக்கும்.

4. `strictVersion` விருப்பம்

strictVersion இயக்கப்பட்டிருக்கும்போது (இது requiredVersion-க்கான இயல்புநிலை), ஒரு சார்புநிலையை பூர்த்தி செய்ய முடியாவிட்டால் Module Federation ஒரு பிழையை வீசுகிறது. strictVersion: false என அமைப்பது மென்மையான பதிப்பு கையாளுதலுக்கு அனுமதிக்கலாம், அங்கு Module Federation ஒரு புதிய பதிப்பு கிடைக்கவில்லை என்றால் ஒரு பழைய பதிப்பைப் பயன்படுத்த முயற்சிக்கும், ஆனால் இது ரன்டைம் பிழைகளுக்கு வழிவகுக்கும்.

பகிரப்பட்ட Scope-ஐப் பயன்படுத்துவதற்கான சிறந்த நடைமுறைகள்

Module Federation-இன் பகிரப்பட்ட ஸ்கோப்பை திறம்படப் பயன்படுத்தவும், பொதுவான இடர்களைத் தவிர்க்கவும், இந்த சிறந்த நடைமுறைகளைக் கவனியுங்கள்:

1. பகிரப்பட்ட சார்புநிலைகளை மையப்படுத்துங்கள்: கட்டமைப்புகள் (React, Vue, Angular), UI கூறு நூலகங்கள் மற்றும் நிலை மேலாண்மை நூலகங்கள் போன்ற பொதுவான, நிலையான சார்புநிலைகளுக்கான உண்மையின் ஆதாரமாக ஒரு முதன்மை செயலியை (பெரும்பாலும் கண்டெய்னர் அல்லது ஒரு பிரத்யேக பகிரப்பட்ட நூலக செயலி) நியமிக்கவும்.
2. பரந்த பதிப்பு வரம்புகளை வரையறுக்கவும்: முதன்மை பகிர்வு செயலியில் பகிரப்பட்ட சார்புநிலைகளுக்கு SemVer வரம்புகளை (எ.கா., '^18.0.0') பயன்படுத்தவும். இது மற்ற செயலிகள் முழு சுற்றுச்சூழல் அமைப்பிலும் கடுமையான புதுப்பிப்புகளை கட்டாயப்படுத்தாமல் இணக்கமான பதிப்புகளைப் பயன்படுத்த அனுமதிக்கிறது.
3. பகிரப்பட்ட சார்புநிலைகளை தெளிவாக ஆவணப்படுத்துங்கள்: எந்த சார்புநிலைகள் பகிரப்படுகின்றன, அவற்றின் பதிப்புகள் மற்றும் அவற்றைப் பகிர்வதற்கு எந்த செயலிகள் பொறுப்பு என்பது பற்றிய தெளிவான ஆவணங்களை பராமரிக்கவும். இது குழுக்கள் சார்புநிலை வரைபடத்தைப் புரிந்துகொள்ள உதவுகிறது.
4. பண்டில் அளவுகளைக் கண்காணிக்கவும்: உங்கள் செயலிகளின் பண்டில் அளவுகளை தவறாமல் பகுப்பாய்வு செய்யவும். Module Federation-இன் பகிரப்பட்ட ஸ்கோப், பொதுவான சார்புநிலைகள் வெளிப்புறப்படுத்தப்படுவதால், டைனமிக்காக ஏற்றப்பட்ட துண்டுகளின் அளவைக் குறைக்க வழிவகுக்க வேண்டும்.
5. நிர்ணயிக்கப்படாத சார்புநிலைகளைக் கையாளுங்கள்: அடிக்கடி புதுப்பிக்கப்படும் அல்லது நிலையற்ற API-களைக் கொண்ட சார்புநிலைகளுடன் எச்சரிக்கையாக இருங்கள். அத்தகைய சார்புநிலைகளைப் பகிர்வதற்கு மிகவும் கவனமான பதிப்பு மேலாண்மை மற்றும் சோதனை தேவைப்படலாம்.
6. eager: true-ஐ நியாயமாகப் பயன்படுத்தவும்: eager: true ஒரு சார்புநிலை முன்கூட்டியே ஏற்றப்படுவதை உறுதிசெய்தாலும், அதிகப்படியான பயன்பாடு பெரிய ஆரம்ப சுமைகளுக்கு வழிவகுக்கும். செயலியின் தொடக்கத்திற்கு அவசியமான முக்கியமான நூலகங்களுக்கு இதைப் பயன்படுத்தவும்.
7. சோதனை முக்கியமானது: உங்கள் மைக்ரோஃபிரண்ட்எண்டுகளின் ஒருங்கிணைப்பை முழுமையாக சோதிக்கவும். பகிரப்பட்ட சார்புநிலைகள் சரியாக ஏற்றப்படுவதையும், பதிப்பு முரண்பாடுகள் நேர்த்தியாக கையாளப்படுவதையும் உறுதிப்படுத்தவும். ஒருங்கிணைப்பு மற்றும் எண்ட்-டு-எண்ட் சோதனைகள் உட்பட தானியங்கு சோதனை இன்றியமையாதது.
8. எளிமைக்காக மோனோரெபோக்களைக் கருத்தில் கொள்ளுங்கள்: Module Federation உடன் தொடங்கும் குழுக்களுக்கு, ஒரு மோனோரெபோவிற்குள் பகிரப்பட்ட சார்புநிலைகளை நிர்வகிப்பது (Lerna அல்லது Yarn Workspaces போன்ற கருவிகளைப் பயன்படுத்தி) அமைப்பை எளிதாக்கலாம் மற்றும் நிலைத்தன்மையை உறுதி செய்யலாம். `packageDir` விருப்பம் இங்கு குறிப்பாக பயனுள்ளதாக இருக்கும்.
9. `shareKey` மற்றும் `shareScope` உடன் விளிம்பு நிலைகளைக் கையாளுங்கள்: நீங்கள் சிக்கலான பதிப்பக சூழ்நிலைகளை எதிர்கொண்டால் அல்லது ஒரே நூலகத்தின் வெவ்வேறு பதிப்புகளை வெளிப்படுத்த வேண்டியிருந்தால், மேலும் நுணுக்கமான கட்டுப்பாட்டிற்கு `shareKey` மற்றும் `shareScope` விருப்பங்களை ஆராயுங்கள்.
10. பாதுகாப்பு கருத்தில் கொள்ள வேண்டியவை: பகிரப்பட்ட சார்புநிலைகள் நம்பகமான மூலங்களிலிருந்து பெறப்படுவதை உறுதிசெய்யவும். உங்கள் பில்ட் பைப்லைன் மற்றும் வரிசைப்படுத்தல் செயல்முறைக்கு பாதுகாப்பு சிறந்த நடைமுறைகளைச் செயல்படுத்தவும்.

உலகளாவிய தாக்கம் மற்றும் கருத்தில் கொள்ள வேண்டியவை

உலகளாவிய மேம்பாட்டுக் குழுக்களுக்கு, Module Federation மற்றும் அதன் பகிரப்பட்ட ஸ்கோப் குறிப்பிடத்தக்க நன்மைகளை வழங்குகின்றன:

• பிராந்தியங்கள் முழுவதும் நிலைத்தன்மை: அனைத்து பயனர்களும், அவர்களின் புவியியல் இருப்பிடத்தைப் பொருட்படுத்தாமல், ஒரே முக்கிய சார்புநிலைகளுடன் செயலியை அனுபவிப்பதை உறுதிசெய்கிறது, பிராந்திய முரண்பாடுகளைக் குறைக்கிறது.
• விரைவான மறு செய்கை சுழற்சிகள்: வெவ்வேறு நேர மண்டலங்களில் உள்ள குழுக்கள் சுயாதீனமான அம்சங்கள் அல்லது மைக்ரோஃபிரண்ட்எண்டுகளில் வேலை செய்யலாம், பொதுவான நூலகங்களை நகலெடுப்பது அல்லது சார்புநிலை பதிப்புகள் குறித்து ஒருவருக்கொருவர் காலடி வைப்பது பற்றி தொடர்ந்து கவலைப்படாமல்.
• பல்வேறு நெட்வொர்க்குகளுக்கு உகந்ததாக்கப்பட்டது: பகிரப்பட்ட சார்புநிலைகள் மூலம் ஒட்டுமொத்த பதிவிறக்க அளவைக் குறைப்பது, உலகின் பல பகுதிகளில் பரவலாக உள்ள மெதுவான அல்லது அளவிடப்பட்ட இணைய இணைப்புகளில் உள்ள பயனர்களுக்கு குறிப்பாக நன்மை பயக்கும்.
• எளிமைப்படுத்தப்பட்ட உள்நுழைவு: ஒரு பெரிய திட்டத்தில் சேரும் புதிய டெவலப்பர்கள், பொதுவான நூலகங்கள் தெளிவாக வரையறுக்கப்பட்டு பகிரப்படும்போது, செயலியின் கட்டமைப்பு மற்றும் சார்புநிலை நிர்வாகத்தை எளிதாக புரிந்து கொள்ள முடியும்.

இருப்பினும், உலகளாவிய குழுக்கள் பின்வருவனவற்றையும் கவனத்தில் கொள்ள வேண்டும்:

• CDN உத்திகள்: பகிரப்பட்ட சார்புநிலைகள் ஒரு CDN-இல் ஹோஸ்ட் செய்யப்பட்டால், CDN அனைத்து இலக்கு பிராந்தியங்களுக்கும் நல்ல உலகளாவிய சென்றடைவு மற்றும் குறைந்த தாமதத்தைக் கொண்டிருப்பதை உறுதிசெய்யவும்.
• ஆஃப்லைன் ஆதரவு: ஆஃப்லைன் திறன்கள் தேவைப்படும் செயலிகளுக்கு, பகிரப்பட்ட சார்புநிலைகள் மற்றும் அவற்றின் கேச்சிங்கை நிர்வகிப்பது மிகவும் சிக்கலானதாகிறது.
• ஒழுங்குமுறை இணக்கம்: நூலகங்களைப் பகிர்வது வெவ்வேறு அதிகார வரம்புகளில் உள்ள எந்தவொரு தொடர்புடைய மென்பொருள் உரிமம் அல்லது தரவு தனியுரிமை விதிமுறைகளுக்கும் இணங்குவதை உறுதிசெய்யவும்.

பொதுவான இடர்களும் அவற்றைத் தவிர்ப்பதற்கான வழிகளும்

1. தவறாக உள்ளமைக்கப்பட்ட `singleton`

சிக்கல்: ஒரே ஒரு நிகழ்வை மட்டுமே கொண்டிருக்க வேண்டிய நூலகங்களுக்கு singleton: true என அமைக்க மறப்பது.

தீர்வு: உங்கள் செயலிகள் முழுவதும் தனித்துவமாகப் பகிர விரும்பும் கட்டமைப்புகள், நூலகங்கள் மற்றும் பயன்பாடுகளுக்கு எப்போதும் singleton: true என அமைக்கவும்.

2. சீரற்ற பதிப்பு தேவைகள்

சிக்கல்: வெவ்வேறு செயலிகள் ஒரே பகிரப்பட்ட சார்புநிலைக்கு மிகவும் வேறுபட்ட, பொருந்தாத பதிப்பு வரம்புகளைக் குறிப்பிடுவது.

தீர்வு: பதிப்பு தேவைகளை தரப்படுத்தவும், குறிப்பாக கண்டெய்னர் செயலியில். பரந்த SemVer வரம்புகளைப் பயன்படுத்தவும் மற்றும் எந்த விதிவிலக்குகளையும் ஆவணப்படுத்தவும்.

3. அத்தியாவசியமற்ற நூலகங்களை அதிகமாகப் பகிர்தல்

சிக்கல்: ஒவ்வொரு சிறிய பயன்பாட்டு நூலகத்தையும் பகிர முயற்சிப்பது, இது சிக்கலான உள்ளமைவு மற்றும் சாத்தியமான மோதல்களுக்கு வழிவகுக்கிறது.

தீர்வு: பெரிய, பொதுவான மற்றும் நிலையான சார்புநிலைகளைப் பகிர்வதில் கவனம் செலுத்துங்கள். சிறிய, அரிதாகப் பயன்படுத்தப்படும் பயன்பாடுகள் சிக்கலைத் தவிர்க்க உள்நாட்டில் பண்டில் செய்யப்படுவது நல்லது.

4. `remoteEntry.js` கோப்பை சரியாகக் கையாளாதது

சிக்கல்: `remoteEntry.js` கோப்பு அணுக முடியாததாக இருப்பது அல்லது நுகர்வோர் செயலிகளுக்கு சரியாக வழங்கப்படாதது.

தீர்வு: ரிமோட் உள்ளீடுகளுக்கான உங்கள் ஹோஸ்டிங் உத்தி வலுவானது என்பதையும், `remotes` உள்ளமைவில் குறிப்பிடப்பட்டுள்ள URL-கள் துல்லியமானவை மற்றும் அணுகக்கூடியவை என்பதையும் உறுதிப்படுத்தவும்.

5. `eager: true` தாக்கங்களை புறக்கணித்தல்

சிக்கல்: அதிகமான சார்புநிலைகளில் eager: true என அமைப்பது, மெதுவான ஆரம்ப ஏற்றுதல் நேரத்திற்கு வழிவகுக்கிறது.

தீர்வு: உங்கள் செயலிகளின் ஆரம்ப ரெண்டரிங் அல்லது முக்கிய செயல்பாட்டிற்கு முற்றிலும் முக்கியமான சார்புநிலைகளுக்கு மட்டுமே eager: true-ஐப் பயன்படுத்தவும்.

முடிவுரை

JavaScript Module Federation-இன் பகிரப்பட்ட ஸ்கோப் என்பது நவீன, அளவிடக்கூடிய வலை செயலிகளை உருவாக்குவதற்கான ஒரு சக்திவாய்ந்த கருவியாகும், குறிப்பாக மைக்ரோஃபிரண்ட்எண்ட் கட்டமைப்பிற்குள். திறமையான சார்புநிலை பகிர்வை செயல்படுத்துவதன் மூலம், இது குறியீடு நகலெடுப்பு, வீக்கம் மற்றும் சீரற்ற தன்மை போன்ற சிக்கல்களைச் சமாளிக்கிறது, இது மேம்பட்ட செயல்திறன் மற்றும் பராமரிப்பிற்கு வழிவகுக்கிறது. shared விருப்பத்தை, குறிப்பாக singleton மற்றும் requiredVersion பண்புகளைப் புரிந்துகொண்டு சரியாக உள்ளமைப்பது இந்த நன்மைகளைத் திறப்பதற்கான திறவுகோலாகும்.

உலகளாவிய மேம்பாட்டுக் குழுக்கள் மைக்ரோஃபிரண்ட்எண்ட் உத்திகளை பெருகிய முறையில் பின்பற்றுவதால், Module Federation-இன் பகிரப்பட்ட ஸ்கோப்பில் தேர்ச்சி பெறுவது மிக முக்கியமானது. சிறந்த நடைமுறைகளைக் கடைப்பிடிப்பதன் மூலமும், பதிப்பகத்தை கவனமாக நிர்வகிப்பதன் மூலமும், முழுமையான சோதனைகளை நடத்துவதன் மூலமும், நீங்கள் இந்த தொழில்நுட்பத்தைப் பயன்படுத்தி வலுவான, உயர் செயல்திறன் கொண்ட மற்றும் பராமரிக்கக்கூடிய செயலிகளை உருவாக்கலாம், அவை ஒரு பன்முக சர்வதேச பயனர் தளத்திற்கு திறம்பட சேவை செய்யும்.

பகிரப்பட்ட ஸ்கோப்பின் சக்தியைத் தழுவி, உங்கள் நிறுவனத்தில் மிகவும் திறமையான மற்றும் கூட்டுறவு வலை மேம்பாட்டிற்கு வழி வகுங்கள்.